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Resume 

Un verificateur de modele peut produire une trace de 
contre-exemple, pour un programme errone, qui est sou- 
vent longue et difPicile a comprendre. En general, la par- 
tie qui concerne les boucles est la plus importante parmi 
les instructions de cette trace. Ce qui rend la localisation 
d'erreurs dans les boucles cruciale, pour analyser les er- 
reurs dans le programme en global. Dans ce papier, nous 
explorons les capacites de la scalabilite de LocFaults, 
notre approche de localisation d'erreurs exploitant les 
chemins du CFG(Controle Flow Graph) a partir d'un 
contre-exemple pour calculer les DGMs(Deviations de 
Gorrection Minimales), ainsi les MGSs(Minimal Correc¬ 
tion Subsets) a partir de chaque DCM. Nous presentons 
les temps de notre approche sur des programmes avec 
boucles While depliees b fois, et un nombre de condi¬ 
tions devises allant de 0 a n. Nos resultats preliminaires 
montrent que les temps de notre approche, bases sur 
les contraintes et dirigee par les flots, sont meilleurs par 
rapport a BugAssist qui se base sur SAT et transforms 
la totalite du programme en une formule booleenne, et 
de plus I'information fournie par LocFaults est plus ex¬ 
pressive pour I'utiiisateur. 

Abstract 

A model checker can produce a trace of counte¬ 
rexample, for a erroneous program, which is often long 
and difficult to understand. In general, the part about the 
loops is the largest among the instructions in this trace. 
This makes the location of errors in loops critical, to ana¬ 
lyze errors in the overall program. In this paper, we ex¬ 
plore the scalability capabilities of LocFaults, our error 
localization approach exploiting paths of CFG(Control 
Flow Graph) from a counterexample to calculate the 
MCDs (Minimal Gorrection Deviations), and MGSs (Mi¬ 
nimal Gorrection Subsets) from each MCD found. We 
present the times of our approach on programs with 
l/l/h/Ve-loops unfolded b times, and a number of diver¬ 
ted conditions ranging from 0 to n. Our preliminary re¬ 
sults show that the times of our approach, constraint- 
based and flow-driven, are better compared to BugAs¬ 
sist which is based on SAT and transforms the entire 


program to a Boolean formula, although the information 
provided by LocFaults is more expressive for the user. 


1 Introduction 

Les erreurs dans un programme sont inevitables, 
elles peuvent nuire a son bon fonctionnement et avoir 
des consequences financieres extremement graves et 
presenter une menace pour le bien-etre humain [8]. 
Le lien suivant [7] cite des histoires recentes de bugs 
logiciels. Consequemment, le processus de debogage 
(la detection, la localisation et la correction d’er- 
reurs) est essentiel. La localisation d’erreurs est I’etape 
qui coute le plus. Elle consiste a identifier I’empla- 
cement exact des instructions suspectes [6] afin d’ai- 
der I’utiiisateur a comprendre pourquoi le programme 
a echoue, ce qui lui facilite la tache de la correc¬ 
tion des erreurs. En effet, quand un programme P est 
non conforme vis-a-vis de sa specification (P contient 
des erreurs), un verificateur de modele peut pro¬ 
duire une trace d’un contre-exemple, qui est souvent 
longue et difficile a comprendre meme pour les pro- 
grammeurs experimentes. Pour resoudre ce probleme, 
nous avons propose une approche [4] (nommee Loc¬ 
Faults) a base de contraintes qui explore les chemins 
du CFG(Control Flow Graph) du programme a par¬ 
tir du contre-exemple, pour calculer les sous-ensembles 
minimaux permettant de restaurer la conformite du 
programme vis-a-vis de sa postcondition. Assurer que 
notre methode soit hautement scalable pour faire face 
a I’enorme complexite des systemes logiciels est un cri- 
tere important pour sa qualite [1]. 

Dans ce papier, nous explorons le passage a I’echelle 
de LocFaults sur des programmes avec boucles While 
depliees h fois, et un nombre de conditions devices al¬ 
lant de 0 a 3. 

L’idee de notre approche est de reduire le probleme 




de la localisation d’erreurs vers celui qui consiste a 
calculer un ensemble minimal qui explique pourquoi 
un CSP (Constraint Satisfaction Problem) est infai- 
sable. Le CSP represente bunion des contraintes du 
contre-exemple, du programme et de bassertion vio- 
lee. L’ensemble calcule pent etre un MCS (Minimal 
Correction Subset) on MUS (Minimal Unsatisfiable 
Subset). En gen&al, tester la faisabilite d’un CSP sur 
un domaine fini est un probleme NP-Complet (intrai- 
table) ^, la classe des problemes les plus difliciles de 
la classe NP. Cela vent dire, expliquer binfaisabilite 
dans un CSP est aussi dur, voire plus (on peut classer 
le probleme comme NP-Difficile). BugAssist [9] [10] 
est une methode de localisation d’erreurs qui utilise 
un solveur Max-SAT pour calculer la fusion des MCSs 
de la formule Booleenne du programme en entier avec 
le contre-exemple. Elle devient inefficace pour les pro¬ 
grammes de grande taille. LocFaults travaille aussi a 
partir d’un contre-exemple pour calculer les MCSs. La 
contribution de notre approche par rapport a BugAs¬ 
sist peut se resumer dans les points suivants : 

* Nous ne transformons pas la totalite du pro¬ 
gramme en un systeme de contraintes, mais nous 
utilisons le CFG du programme pour collector 
les contraintes du chemin du contre-exemple et 
des chemins derives de ce dernier, en suppo- 
sant qu’au plus k instructions conditionnelles sont 
susceptibles de contenir les erreurs. Nous cal¬ 
culous les MCSs uniquement sur le chemin du 
contre-exemple et les chemins qui corrigent le pro¬ 
gramme ; 

* Nous ne traduisons pas les instructions du pro¬ 
gramme en une formule SAT, mais plutot en 
contraintes numeriques qui vont etre manipulees 
par des solveurs de contraintes; 

* Nous n’utilisons pas des solveurs MaxSAT comme 
boites noires, mais plutot un algorithme generique 
pour calculer les MCSs par busage d’un solveur de 
contraintes; 

* Nous bornons la taille des MCSs generes et le 
nombre de conditions devices; 

* Nous pouvons faire collaborer plusieurs solveurs 
durant le processus de localisation et prendre ce¬ 
lui le plus performant selon la categoric du CSP 
construit. Exemple, si le CSP du chemin detecte 
est du type lineaire sur les entiers, nous faisons 
appel a un solveur MIP (Mixed Integer Program¬ 
ming) ; s’il est non lineaire, nous utilisons un 
solveur CP (Constraint Programming) ou aussi 
MINLP (Mixed Integer Nonlinear Programming). 

Notre experience pratique a montre que toutes ces 
restrictions et distinctions ont permis a LocFaults 


1. Si ce probleme pouvait etre resolu en temps polynomial, 
alors tons les problemes NP-Complet le seraient aussi. 


d’etre plus rapide et plus expressif. 

Le papier est organise comme suit. La section 2 in- 
troduit la definition d’un MUS et MCS. Dans la section 
3, nous definirons le probleme < fc-DCM. Nous expli- 
quons une contribution du papier pour le traitement 
des boucles erronees, notamment le bug OjJ-by-one, 
dans la section 4. Une breve description de notre algo¬ 
rithme LocFaults est fournie dans la section 5. L’eva¬ 
luation experimentale est presentee dans la section 6. 
La section 7 parle de la conclusion et de nos travaux 
futurs. 

2 Definitions 

Dans cette section, nous introduirons la definition 
d’un IIS/MUS et MCS. 

CSP Un C'S'P(Constraint Satisfaction Problem) P 
est un triplet < X,D,C > tel que : 

* A un ensemble de n variables xi, X 2 ,..., 

* D le n-uplet < ■■■, >■ L’ensemble 

Dxi contient les valeurs de la variable Xi. 

* C'={ci, C 2 ,..., c„} est bensemble des contraintes. 

Une solution pour P est une instanciation des va¬ 
riables X € D qui satisfait toutes les contraintes dans 
C. P est infaisable s’il ne dispose pas de solutions. Un 
sous-ensemble de contraintes C dans C est dit aussi 
infaisable pour la meme raison sauf qu’ici on se limite 
a bensemble des contraintes dans C. 

On note par : 

~ Sol{< X,C',D >) = 0, pour specifier que C n’a 
pas de solutions, et done il est infaisable. 

- Sol{< X,C',D >) 7 ^ 0, pour specifier que C dis¬ 
pose d’au moins une solution, et done il est fai- 
sable. 

On dit que P est en forme lineaire et on note 
LP (Linear Program) ssi toutes les contraintes dans C 
sont des equations/inegalites lineaires, il est continu si 
le domaine de toutes les variables est celui des reels. Si 
au moins une des variables dans X est du type entier 
ou binaire (cas special d’un entier), et les contraintes 
sont lineaires, P est dit un programme lineaire mixte 
MIP (Mixed-integer linear program). Si les contraintes 
sont non-lineaires, on dit que P est un programme non 
lineaire NLP(NonLinear Program). 

Soit P =< X,D,C > un CSP infaisable, on definit 
pour P : 

IS Un IS (Inconsistent Set) est un sous-ensemble de 
contraintes infaisable dans bensemble de contraintes 
infaisable C. C est un IS ssi : 

* C CC. 



* Sol{<X,C',D>)=%. 


IIS ou MUS Un IIS (Irreducible Inconsistent Set) 
ou MUS (Minimal Unsatisfiable Subset) est un sous- 
ensemble de contraintes infaisable de C, et tous ses 
sous-ensembles stricts sont faisables. C est un IIS ssi: 

* C est un IS. 

* V C" C C'.Sol{< X,C",D >) + 0, (chacune de 
ses parties contribue a I’infaisabilite), C est dit 
irreductible. 


MCS C est un MCS(Minimal Correction Set) ssi : 

* C QC. 

* Sol{< X,C\C',D >) 

* $C'' C C tel que Sol{< X, C\C", >) ^ 0. 


3 Le probleme < /c-DCM 

Etant donne un programme errone modelise en un 
CFG^ G = {C,A,E) : C est I’ensemble des noeuds 
conditionnels; A est I’ensemble des blocs d’affecta- 
tion; E est I’ensemble des arcs, et un contre-exemple. 
Une DCM {Deviation de Correetion Minimale) est un 
ensemble D Q C telle que la propagation du contre- 
exemple sur I’ensemble des instructions de G a partir 
de la racine, tout en ayant nie chaque condition^ dans 
D, permet en sortie de satisfaire la postcondition. Elle 
est dite minimale (ou irreductible) dans le sens ou au- 
cun element ne peut etre retire de D sans que celle-ci 
ne perde cette propriete. En d’autres termes, D est une 
correction minimale du programme dans I’ensemble 
des conditions. La taille d’une deviation minimale est 
son cardinal. Le probleme < k-DCM consiste a trou- 
ver toutes les DCMs de taille inferieure ou egale a k. 

Exemple, le GFG du programme AbsMinus (voir fig. 
2) possede une deviation minimale de taille 1 pour 
le contre-exemple {i = 0,j = 1}. Certes, la devia¬ 
tion {*0 < jo,ki = 1 A fo 7 ^ jo} permet de cor- 
riger le programme, mais elle n’est pas minimale; 
la seule deviation minimale pour ce programme est 
{fci = 1 A lo 7^ jo}. 

Le tableau ci-dessous recapitule le deroule- 
ment de LocFaults pour le programme AbsMi¬ 
nus, avec au plus 2 conditions devices a par¬ 
tir du contre-exemple suivant {i = 0,j = 1}. 


2. Nous utilisons la transformation en forme DSA [5] qui as¬ 
sure que chaque variable est affectee une seule fois sur chaque 
chemin du CFG. 

3. On nie la condition afin de prendre la branche opposee a 
celle ou on devait aller. 



Figure 1 - Le programme Figure 2 - Le cfg dsa 

AbsMinus de AbsMinus 




Conditions devices 

DCM 

MCS 

Figure 

0 

1 

{ri = iQ - JO : 15} 

fig. 3 

{■*0 < JO ■ 8} 

Non 

/ 

fig. 4 

{fcl = 1 A io! = JO ■■ 11} 

Oui 

{fco = 0 : 7}, 

{fcl = fcO + 2 : 9} 

fig. 5 

{•iO ^ ■JO ■ 8, 
fcl = 1 A io’ = JO : 11} 

Non 

/ 

fig. 6 


Nous avons affiche les conditions devices, si elles 
constituent une deviation minimale ou non, les 
MCSs calcules a partir du systeme construit : voir 
respectivement les colonnes I, 2 et 3. La colonne 4 
indique la figure qui illustre le chemin explore pour 
chaque deviation. Sur la premiere et la troisieme 
colonne, nous avons affiche en plus de I’instruction sa 






































































ligne dans le programme. Exemple, la premiere ligne 
dans le tableau montre qu’il y a un seul MCS trouve 
({ri = io — jo ■ 15}) sur le chemin du contre-exemple. 


viation ainsi que le chemin au-dessus de la condition 
device sont illustres en vert). 


4 Traitement des boucles 

Dans le cadre du Bounded Model Checking (BMC) 
pour les programmes, le depliage peut etre applique au 
programme en entier comme il peut etre applique aux 
boucles separement [1]. Notre approche de localisation 
d’erreurs, LocFaults [3] [4], se place dans la deuxieme 
demarche; c’est-a-dire, nous utilisons une borne b pour 
deplier les boucles en les remplagant par des imbrica¬ 
tions de conditionnelles de profondeur b. Considerons 
le programme Minimum (voir fig. 7) contenant une 
seule boucle, qui calcule le minimum dans un tableau 
d’entiers. L’effet sur le graphe de hot de controle du 
programme Minimum avant et apres le depliage est 
illustre sur les figures respectivement 7 et 8 : la boucle 
While est depliee 3 fois, tel que 3 est le nombre d’ite- 
rations necessaires a la boucle pour calculer la valeur 
minimum dans un tableau de taille 4 dans le pire des 
cas. 

LocFaults prend en entree le CFG du programme 
errone, CE un contre-exemple, bdcm ■ une borne sur le 
nombre de conditions devices, bmcs ■ une borne sur la 
taille des MCSs calcules. II permet d’explorer le CFG 
en profondeur en deviant au plus bdcm conditions par 
rapport au comportement du contre-exemple : 

* II propage le contre-exemple jusqu’a la postcon¬ 
dition. Fnsuite, il calcule les MCSs sur le CSP 
du chemin genere pour localiser les erreurs sur le 
chemin du contre-exemple. 

* Il cherche a enumerer les ensembles < bdcm-^GM. 
Pour chaque DCM trouvee, il calcule les MCSs 
dans le chemin qui arrive a la derniere condition 
device et qui permet de prendre le chemin de la 
deviation. 

Parmi les erreurs les plus courantes associees aux 
boucles selon [2], le bug Off-by-one, c’est-a-dire, des 
boucles qui s’iterent une fois de trop ou de moins. Cela 
peut etre du a une mauvaise initialisation des variables 
de controle de la boucle, ou a une condition incorrecte 
de la boucle. Le programme Minimum presente un cas 
de ce type d’erreur. Il est errone a cause de sa boucle 
While, I’instruction falsifiee se situe sur la condition 
de la boucle (ligne 9) : la condition correcte doit etre 
{i < tab.length) (tab.length est le nombre d’elements 
du tableau tab). A partir du contre-exemple suivant : 
{fa6[0] = 3,to&[I] = 2,tab[2] = I,to6[3] = 0}, nous 
avons illustre sur la figure 8 le chemin fautif initial 
(voir le chemin colore en rouge), ainsi que la deviation 
pour laquelle la postcondition est satisfaisable (la de¬ 
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class Minimum { 

/* The minimum in an 

array of n integers 
*/ 

/*@ ensures 

@ (\forall int k;(k >= 
0 k < tab . 

length ) ; tab [k] >= 

@ ’ 

int Minimum (int [] tab) 
{ 

int min=t ab [ 0 ] ; 
int i = 1 ; 
while ( i<tab . length 
-1) { /* error , 

the condition 
should be (i<tab 
. length ) */ 
if (tab [ i]< = min) { 
min=t ab [ i ] ; 

} 

i = i+l; 

} 

return min; 

} 

} 


= £ab|0P 



Figure 7 - Le programme Minimum et son CFG nor¬ 
mal (non deplie). La postcondition est {V int k; (k > 
0 A fc < tab.length)] tab[k] > min} 

Nous afhchons dans le tableau ci-dessous les chemins 
errones generes (la colonne PATH) ainsi que les MCSs 
calcules (la colonne MCSs) pour au plus 1 condi¬ 
tion device par rapport au comportement du contre- 
exemple. La premiere ligne correspond au chemin du 
contre-exemple; la deuxieme correspond au chemin 
obtenu en deviant la condition {i 2 < tabo.length — 1}. 


PATH 

MCSs 

{CE : [tabo[0] = 3 A tabo[l] = 2 A tabo[2] = 1 
Atabo[3] == 0], miriQ = tabo[0]- = 1. 

mini = tabo[io]<n = ^0 + l,min2 = taboful. 

12 = ‘il + l,min^ = min^, ^3 = i2> 

POST : [(tab[0] > min^) A (tab[l] > min^) 
A{tab[21 > min,) A {tab[31 > min,)U 

{min2 = tabo[il]} 

{CE : [tabo [0] = 3 A tabQ [1] = 2 A tabQ [2] = 1 
Atabo[3] == 0], minQ = tabo[0], iQ = 1, 
mini = = *0 + litTi,in 2 = tabo[ii], 

^ 2 =^ 1 + < tabo.length - 1 )] 

{io = 1 >. 

(il = io + 1 }, 

{i 2 = il + 1 } 


LocFaults a permis d’identifier un seul MCS sur le 
chemin du contre-exemple qui contient la contrainte 
min 2 = tabid[ii], I’instruction de la ligne 11 dans la 
deuxieme iteration de la boucle depliee. Avec une 
condition device, I’algorithme suspecte la troisieme 
condition de la boucle depliee, i 2 < tabo.length — 1; 
en d’autres termes, il faut une nouvelle iteration pour 
satisfaire la postcondition. 

Get exemple montre un cas d’un programme avec 
une boucle erronee : I’erreur est sur le critere d’arret, 
elle ne permet pas en effet au programme d’iterer jus- 
qu’au dernier element du tableau en entree. LocFaults 
avec son mecanisme de deviation arrive a supporter 
ce type d’erreur avec precision. Il fournit a I’utilisa- 
teur non seulement les instructions suspectes dans la 
boucle non depliee du programme original, mais aussi 
des informations sur les iterations ou elles se situent 



















Figure 8 “ Figure montrant le CFG en forme DSA du pro¬ 
gramme Minimum en depliant sa boucle 3 fois, avec le chemin d’un 
contre-exemple (illustre en rouge) et une deviation satisfaisant sa 
postcondition (illustree en vert). 

concretement en depliant la boucle. Ces informations 
pourraient etre tres utiles pour le programmeur pour 
mieux comprendre les erreurs dans la boucle. 

5 Algorithme ameliore 

Notre but consiste a trouver les DCMs de taille in- 
ferieure a une borne k ; en d’autres termes, on cherche 
a donner une solution an probleme pose ci-dessus 
(< fc-DCM). Pour cela, notre algorithme (nomme Loc- 
Faults) parcourt en profondeur le CFG et genere les 
chemins oil au plus k conditions sont deviees par rap¬ 
port au comportement du contre-exemple. 

Pour ameliorer TefScacite, notre solution heuristique 
procede de fagon incrementale. File devie successive- 
ment de 0 a fc conditions et elle recherche les MCSs 
pour les chemins correspondants. Toutefois, si a I’etape 
k LocFaults a devie une condition Cj et que cela a cor- 


rige le programme, elle n’explorera pas a I’etape fc' avec 
fc' > fc les chemins qui impliquent une deviation de la 
condition c^. Pour cela, nous ajoutons la cardinalite de 
la deviation minimale trouvee (fc) comme information 
sur le noeud de c^. 

Nous allons sur un exemple illustrer le deroule- 
ment de notre approche, voir le graphe sur la fi¬ 
gure 9. Chaque cercle dans le graphe represente un 
noeud conditionnel visite par I’algorithme. L’exemple 
ne montre pas les blocs d’affectations, car nous voulons 
illustrer uniquement comment nous trouverons les de¬ 
viations de correction minimales d’une taille bornee de 
la maniere citee ci-dessus. Un arc reliant une condition 
Cl a une autre C 2 illustre que C 2 est atteinte par I’al- 
gorithme. II y a deux fagons, par rapport au compor¬ 
tement du contre-exemple, par lesquelles LocFaults 
arrive a la condition C 2 : 

1. en suivant la branche normale induite par la 
condition ci; 

2. en suivant la branche opposee. 

La valeur de I’etiquette des arcs pour le cas (1) (resp. 
(2)) est "next” (resp. "devie"). 



le chemin < 1, 2, 3, 4, 5, 6, 7, POST > est correct 
le chemin < 1, 8, 9, 10, 11, 12, 7, ..., POST > est correct 

Figure 9 — Figure illustrant Fexecution de notre algorithme 
sur un exemple pour lequel deux deviations minimales sont 
detectees : {1,2,3,4,7} et {8,9,11,12,7}, et une abandon- 
nee : {8,13,14,15,16, 7}. Sachant que la deviation de la condi¬ 
tion ”7” a permis de corriger le programme pour le chemin < 
1, 2, 3, 4,5, 6 >, ainsi que pour le chemin < 1, 8, 9,10,11,12, 7 >. 

- A I’etape fc = 5, notre algorithme a identifie deux 
deviations minimales de taille egale a 5 : 








































1. Di = {1,2,3,4, 7}, le noeud ”7” est marque 
par la valeur 5 ; 

2. £>2 = {8,9,11,12, 7}, elle a ete autorisee, car 
la valeur de la marque du noeud ”7” est egale 
a la cardinalite de 02 - 

- A I’etape fc = 6, I’algorithme a suspendu la de¬ 
viation suivante D 3 = {8,13,14,15,16, 7}, car la 
cardinalite de D 3 est superieure strictement a la 
valeur de I’etiquette du noeud ”7”. 

6 Experience pratique 

Pour evaluer la scalabilite de notre methode, nous 
avons compare ses performances avec cedes de BugAs- 
sist^ sur deux ensembles de benchmarks®. 

* Le premier benchmark est illustratif, il contient 
un ensemble de programmes sans boucles; 

* Le deuxieme benchmark inclut 19, 49 et 91 varia¬ 
tions pour respectivement les programmes Bub- 
bleSort, Sum et SquareRoot. Ces programmes 
contiennent des boucles pour etudier le passage 
a I’echelle de notre approche par rapport a Bu- 
gAssist. Pour augmenter la complexite d’un pro¬ 
gramme, nous augmentons le nombre d’iterations 
dans les boucles a I’execution de chaque outil; 
nous utilisons la meme borne de depliage des 
boucles pour LocFaults et BugAssist. 

Pour generer le CFG et le contre-exemple, nous uti¬ 
lisons I’outil CPBPV [11] (Constraint-Programming 
Framework for Bounded Program Verification). Loc¬ 
Faults et BugAssist travaillent respectivement sur 
des programmes Java et C. Pour que la comparai- 
son soit juste, nous avons construit pour chaque pro¬ 
gramme deux versions equivalentes : 

* une version en Java annotee par une specification 
JML; 

* une version en ANSI-C annotee par la meme spe¬ 
cification mais en ACSL. 

Les deux versions ont les memes numeros de lignes 
d’instructions, notamment des erreurs. La precondi¬ 
tion specific le contre-exemple employe pour le pro¬ 
gramme. 

Pour calculer les MCSs, nous avons utilise les sol- 
veurs IBM ILOG MIP® et CP ^ de CPLEX. Nous 

4. L’outil BugAssist est disponible a Tadresse : http:// 
bugassist.mpi-sws.org/ 

5. Le code source de Tensemble de programmes est dis¬ 
ponible a I’adresse : http://www.i3s.unice.fr/''bekkouch/ 
Benchs.Mohammed.html 

6. Disponible a I’adresse http ://www- 

01. ibm.com / software / commerce / optimization / cplex- 
optimizer/ 

7. Disponible a I’adresse http ://www- 

01 .ibm.com / software/commerce/optimization/cplex-cp- 


avons adapte et implemente Talgorithme de Liffiton et 
Sakallah [12], voir alg. 1. Cette implementation prend 
en entree I’ensemble de contraintes infaisable qui cor¬ 
respond au chemin identifie (C), et bmca '■ la borne sur 
la taille des MCSs calcules. Chaque contrainte a dans 
le systeme construit C est augmentee par un indica- 
teur yi pour donner yi —>■ c* dans le nouveau systeme 
de contraintes C. Affecter a yi la valeur Vrai implique 
la contrainte ; en revanche, affecter a yi la valeur 
Faux implique la suppression de la contrainte Cj. Un 
MCS est obtenu en cherchant une affectation qui satis- 
fait le systeme de contraintes avec un ensemble mini¬ 
mal d’indicateurs de contraintes affectes avec Faux. 
Pour limiter le nombre de variables indicateurs de 
contraintes qui peuvent etre assignees a Faux, on uti¬ 
lise la contrainte AtMost{-<yi, -it/ 2 , •.•, ~'yn, k) (voir la 
ligne 5), le systeme cree est note dans I’algorithme 
(ligne 5). Chaque iteration de la boucle While (lignes 
6 — 19) permet de trouver tous les MCSs de taille k, 
k est incremente de 1 apres chaque iteration. Apres 
chaque MCS trouve (lignes 8 — 13), une contrainte de 
blocage est ajoutee a et C pour empecher de trou¬ 
ver ce nouveau MCS dans les prochaines iterations 
(lignes 15 — 16). La premiere boucle (lignes 4 — 19) 
s’itere jusqu’a ce que tous les MCSs de C soient gene- 
res (C" devient infaisable); elle peut s’arreter aussi si 
les MCSs de taille inferieure ou egale bmcs sont obtenus 
{k > ^mcs)- 


Fonction MCS(C,6mcs) 

Entrees; C : Ensemble de contraintes infaisable, bmcs • Entier 
Sorties: MCS : Liste de MCSs de C de cardinalite inferieure a b-mcs 
debut 

C' ^ AddYVars(C); MCS •(- 0 ; fc ■(- 1; 
tant que SAT(C^) A fc < bmcs faire 
I Cf^ ■(- C' A AtMost(Y-'yi , ->^2 ’ -■yn}.fe) 

tant que SAT(C‘f) faire 
■ newMCS ■«- 0 

pour chaque indicateur faire 

% yi est I’indicateur de la contrainte Cj ^ C, et val{yi) la 
valeur de y j dans la solution calculee de . 
si vaKvo') = 0 alors 
I newMCS ^ newMCS \J {ci}. 
fin 


MCS.add(newMCS). 

C^ *— A BlockingClause(rj 
C' ■<— C' A BlockingClause(n« 

■ k + 1 


wMCS) 

uMCS) 


retourner MCS 


Algorithm 1: Algorithme de Liffiton et Sakallah 


BugAssist utilise I’outil CBMC [13] pour generer la 
trace erronee et les donnees d’entree. Pour le solveur 
Max-SAT, nous avons utilise MSUnCore2 [14]. 

Les experimentations ont ete effectuees avec un pro- 
cesseur Intel Core i7-3720QM 2.60 GHz avec 8 GO de 
RAM. 


optimizer/ 



6.1 Le benchmark sans boucles 

Cette partie sert a illustrer 1’amelioration apportfe 
a LocFaults pour reduire le nombre d’ensembles sus¬ 
pects fournis a I’utilisateur : a une etape donnee de 
I’algorithme, le noeud dans le CFG du programme qui 
permet de detecter une DCM sera marque par le car¬ 
dinal de cette derniere; ainsi aux prochaines etapes, 
I’algorithme n’autorisera pas le balayage d’une liste 
d’adjacence de ce noeud. 

Nos resultats® montrent que LocFaults rate les er- 
reurs uniquement pour TritypeKOb. Or, BugAssist 
rate I’erreur pour AbsMinusK02, AbsMinusKOS, Abs- 
MinusV2K02, TritypeKO, TriPerimetreKO, TriMult- 
PerimetreKO et une des deux erreurs dans Trity- 
peK05. Les temps® de notre outil sont meilleurs par 
rapport a BugAssist pour les programmes avec cal- 
cul numerique; ils sont proches pour le reste des pro¬ 
grammes. 

Prenons trois exemples parmi ces programmes au 
hasard. Et considerons rimplementation de deux ver¬ 
sions de notre algorithme, sans et avec marquage des 
noeuds nommees respectivement LocFaultsVl et Loc- 
FaultsV2. 

- Les tables 1 et 2 montrent respectivement les en¬ 
sembles suspects et les temps de LocFaultsVl; 

- Les tables 3 et 4 montrent respectivement les en¬ 
sembles suspects et les temps de LocFaultsV2. 

Dans les tables 1 et 3, nous avons affiche la liste des 
MCSs et DCMs calcules. Le numero de la ligne corres- 
pondant a la condition est souligne. Les tables 2 et 4 
donnent les temps de calcul: P est le temps de pretrai- 
tement qui inclut la traduction du programme Java en 
un arbre syntaxique abstrait avec I’outil JDT (Eclipse 
Java devlopment tools), ainsi que la construction du 
CFG; L est le temps de I’exploration du CFG et de 
calcul des MCSs. 

LocFaultsV2 a permis de reduire considerablement 
les deviations generees ainsi que les temps sommant 
I’exploration du CFG et le calcul des MCSs de Loc¬ 
FaultsVl, et cela sans perdre I’erreur; les localisa¬ 
tions fournies par LocFaultsV2 sont plus pertinentes. 
Les lignes eliminees de la table 3 sont colorees en 
bleu dans la table 1. Les temps ameliores sont affi- 
ches en gras dans la table 4. Par exemple, pour le 
programme TritypeK02, a I’etape 1 de I’algorithme, 

8. Le tableau qui donne les MCSs calcules par Loc¬ 
Faults pour les programmes sans boucles est dispo- 
nible a I’adresse http://www.i3s.unice.fr/''bekkouch/Bench_ 
Mohammed.html#rsb 

9. Les tableaux qui donnent les temps de LocFaults et 
BugAssist pour les programmes sans boucles sont dispo- 
nibles a I’adresse http://www.i3s.unice.fr/''bekkouch/Bench_ 
Mohammed.html#rsba 


LocFaultsV2 marque le noeud de la condition 26, 35 et 
53 (a partir du contre-exemple, le programme devient 
correct en deviant chacune de ces trois conditions). 
Cela permet, a I’etape 2, d’annuler les deviations sui- 
vantes : {26,29}, {26,35}, {29,35}, {32,35}. Toujours 
a I’etape 2, LocFaultsV2 detecte deux deviations mi¬ 
nimales en plus : {29,^}, {^,M}, les noeuds 57 et 
44 vont done etre marques (la valeur de la marque est 
2). A I’etape 3, aucune deviation n’est selectionnee; a 
titre d’exemple, {29,32,44} n’est pas consideree parce 
que son cardinal est superieur strictement a la valeur 
de la marque du noeud 44. 


Programme 

1 LocFaults 1 

P 

1 ^ n 

= 0 

< 1 

< 2 

< 3 

TritypeK02 

0, 471 

0,023 

0, 241 

2,529 

5,879 

TritypeK04 

0,476 

0, 022 

0, 114 

0,348 

5,55 

TriPerimetreKOS 

0,487 

0,052 

0,237 

2,468 

6, 103 


Table 2 — Temps de calcul, pour les resultats sans I’usage du 
marquage des noeuds 


Programme 

1 LocFaults 1 

P 

1 L 1 

= 0 

^1 

< 2 

< 3 

TritypeK02 

0,496 

0, 022 

0, 264 

1,208 

1,119 

TritypeK04 

0,481 

0,021 

0, 106 

0,145 

1,646 

TriPerimetreK03 

0,485 

0,04 

0, 255 

1,339 

1,219 


Table 4 — Temps de calcul, pour les resultats avec I’usage du 
marquage des noeuds 


6.2 Les benchmarks avec boucles 

Ces benchmarks servent a mesurer I’extensibilite de 
LocFaults par rapport a BugAssist pour des pro¬ 
grammes avec boucles, en fonction de I’augmentation 
du nombre de depliage b. Nous avons pris trois pro¬ 
grammes avec boucles : BubbleSort, Sum et Square- 
Root. Nous avons provoque le bug Off-by-one dans 
chacun. Le benchmark, pour chaque programme, est 
cree en faisant augmenter le nombre de depliage b. b 
est egal au nombre d’iterations effectuees par la boucle 
dans le pire des cas. Nous faisons aussi varier le nombre 
de conditions devices pour LocFaults de 0 a 3. 

Nous avons utilise le solveur MIP de CPLEX pour 
BubbleSort. Pour Sum et SquareRoot, nous avons fait 
collaborer les deux solveurs de CPLEX (CP et MIP) 
lors du processus de la localisation. En effet, lors 
de la collecte des contraintes, nous utilisons une va¬ 
riable pour garder I’information sur le type du CSP 
construit. Quand LocFaults detecte un chemin er- 
rone^® et avant de proceder au calcul des MCSs, il 
prend le bon solveur selon le type du CSP qui cor¬ 
respond a ce chemin : s’il est non lineaire, il utilise le 

10. Un chemin errone est celui sur lequel nous identifions les 
MCSs. 





Programme 


Contre-exemple 


< 3 


{54} 

-fur 


-mr 


{54} 

Tgir 


{35},}27},-f2rr 


Tggr 


{54} 

~rgrr 


{35},}27},-r257' 

{53}.{25},-r27F 




TritypeK02 


{i = 2, j = 2, k = 4} 


{54} 


■i 26. ■i9T~ 


{35},{27},r25r' 

{53},{25},T7rr 


\ 26,29 ^ 


{53}>{25},{27} 






Tmrwrr^ - 

{M,57},|30},{i^7},{i>rr 






{^, ^},{33},{25},{27} 




{29.^. 35}.{33},{25},{27}.{30} 


{46} 


{46} 


^29. 32. 44 K< 33 k {25} .{27}. {30} 


{46} 


{45},} 33},{ 257 - 

^ 26. 32 [- 


{^{.{as},!^;}- 


{29.32 j 

{i5.ii)}.{33}-T^rr 


■i 26, 32 y~ 


~TI1 


^ 29, 32 r~ 

.i0}.{33},{^5r 


TritypeK04 


{i = 2,j = 3,k= 3} 


{46} 


{45}>{33},{25} 


_.M).(33),{25} 

{26,45,ii), {33}, {25},{27} 

{26, 4S, M},{33}.{25}.{27} 


{26,45 


7{,{33},{25}.fT7r 


{M. 53}.{33},{25} 


{29. 32.49|,|30}.{25} 


{li-45, ^>,{33}, {25}, {30} 


{29, 45, 53}, {33}, {25}, {30} 
{29, 45, 57}!{33},{25|.{30} 


{58} 

{ 22 } 


{58} 

{ 22 } 


{32, 35, M).{25} 

{32, 35,57},{25} 


{58} 


{31} 
{37},{32},f2Tr 


TUT 


{ 22 } 


{37},{32},r27F 


{57}, {32},{27} 

{28, 31}.{32}.{27}. {29}- 


{31} 
{37},{32},T2Tr 


TriPerimetreK03 


{i = 2 ,i = 1 , fc = 2 } 


{58} 


{M. ^}, {32}, {27}, {29} 
{31.37}. {277 


{57}, {32},{27} 

{28. 37}.{32}.{27}. {29]- 


{28,61},{32},{27},{29} 


{57.}, {32},{27} 


{M, 37},{35}.{27},{32} 


{31. 37).{27} 

IM. 37}.{35}.{27},{32} 


{34.481.{35},{32},{277~ 


{34, 48},{35},{32},{27} 


{28, 31, 37}.{29}.fTf7 

■{ 28. 31. 52 1-, {29},{27 , 

-i28. 34. 37}-.-{ 35 ki27>,{29>,{32> 


■i 28. 34.48 35 ki 27k< 29 k-l 32 ^ 

^31. 34. 37ki27kr35l 

"TTl. 34. 61 k{27},(35~r 


Table 1 — MCSs et deviations identifies par LocFaults pour des programmes sans boucles, sans I’usage du marquage des noeuds 


Programme 

Contre-exemple 

Erreurs 

LocFaults 

= 0 

^1 

< 2 

< 3 

TritypeK02 

{i = 2, j = 2, fc = 4} 

53 

{54} 

{54} 

{54} 

{54} 

TUT 

TUT 

TUT 

{26} 

{26} 

{26} 

{35},{27},{25} 

{35},{27},{25} 

{35},{27},{25} 

{53}, {25},{27} 

1 53 k i^5} , { 27|- 

I 53 k{^5},{27} 

^ 29, 57L-I 50 r.-! 27},{25} 

{29,57},{50},{27},{25} 

1 32. 44 kl 33 kl 25>, {27> 

{32,44},{33},{25}, {27} 

TritypeK04 

{i = 2, j = 3, fc = 3} 

45 

{46} 

{46} 

{46} 

{46} 

{45}, {33},{25} 

{45}, {33},{25} 

{45}, {33},{25} 

^26. 32}- 

1 26.32 ^ 

{29,32} 

{29,32} 

- {52,55,49},{25} - 

-{M.M.MId^S}- 

132. 35^ 57k{25} 

TriPerimetreKOS 

{i = 2 , j = 1, fc = 2 } 

57 

{58} 

{58} 

{58} 

{58} 

US} 

TUT 

TUT 

{31} 

{31} 

{31} 

{37},{32},{27} 

{37},{32},{27} 

{37},{32},{27} 

{57}, {32},{27} 

1 57 k 1 62} , { 27} 

1 57 k{32},{27} 

{28,61},{52},{27},{29} 

{28,61},{52},{27},{29} 

{M. M}.{35},{32},{27} 

{M.M>.{35},{32},{27} 


Table 3 — MCSs et DCMs identifies par LocFaults pour des programmes sans boucles, avec I’usage du marquage des noeuds 























































































solveur CP OPTIMIZER; sinon, il utilise le solveur 
MIP. 

Pour chaque benchmark, nous avons presente un ex¬ 
trait de la table contenant les temps de calcul (les 
colonnes P et L affichent respectivement les temps 
de pretraitement et de calcul des MCSs), ainsi que le 
graphe qui correspond au temps de calcul des MCSs. 

6.2.1 Le benchmark BubbleSort 

BubbleSort est une implementation de I’algorithme 
de tri a bulles. Ce programme contient deux boucles 
imbriquees ; sa complexite en moyenne est d’ordre n^, 
oil n est la taille du tableau ; le tri a bulles est considere 
parmi les mauvais algorithmes de tri. L’instruction er- 
ronee dans ce programme entraine le programme a 
trier le tableau en entree en considerant seulement ses 
n — I premiers elements. Le mauvais fonctionnement 
du BubbleSort est du au nombre d’iterations insuffi- 
sant effectue par la boucle. Cela est du a I’initialisation 
fautive de la variable i: i = tab.length -1; I’instruction 
devait etre i = tab.length. 


Programs 

b 

LocFaults 

BugAssist 

P 

E 

P 

L 

= 0 

< 1 

< 2 

< 3 

VO 

4 

0.751 

0.681 

0.56 

0.52 

0.948 

0.34 

55.27 

VI 

5 

0.813 

0.889 

0.713 

0.776 

1.331 

0.22 

125.40 

V2 

6 

1.068 

1.575 

1.483 

1.805 

4.118 

0.41 

277.14 

V3 

7 

1.153 

0.904 

0.85 

1.597 

12.67 

0.53 

612.79 

V4 

8 

0.842 

6.509 

6.576 

8.799 

116.347 

1.17 

1074.67 

V5 

9 

1.457 

18.797 

18.891 

21.079 

492.178 

1.24 

1665.62 

V6 

10 

0.941 

28.745 

29.14 

35.283 

2078.445 

1.53 

2754.68 

V7 

11 

0.918 

59.894 

65.289 

74.93 

4916.434 

3.94 

7662.90 


Table 5 - Le temps de calcul pour le benchmark Bub¬ 
bleSort 

Les temps de LocFaults et BugAssist pour le 
benchmark BubbleSort sont presentes dans la table 5. 
Le graphe qui illustre I’augmentation des temps des 
differentes versions de LocFaults et de BugAssist en 
fonction du nombre de depliages est donne dans la fi¬ 
gure 10. 

La duree d’execution de LocFaults et de BugAssist 
croit exponentiellement avec le nombre de depliages; 
les temps de BugAssist sont toujours les plus grands. 
On pent considerer que BugAssist est inefScace pour 
ce benchmark. Les differentes versions de LocFaults 
(avec au plus 3, 2, 1 et 0 conditions devices) restent 
utilisables jusqu’a un certain depliage. Le nombre de 
depliage au-dela de lequel la croissance des temps de 
BugAssist devient redhibitoire est inferieur a celui de 
LocFaults, celui de LocFaults avec au plus 3 condi¬ 
tions devices est inferieur a celui de LocFaults avec 
au plus 2 conditions devices qui est inferieur lui aussi a 



Figure 10 - Comparaison de revolution des temps 
des differentes versions de LocFaults et de BugAssist 
pour le benchmark BubbleSort, en faisant augmenter 
le nombre d’iterations en depliant la boucle. 


celui de LocFaults avec au plus 1 conditions devices. 
Les temps de LocFaults avec au plus 1 et 0 condition 
device sont presque les memes. 


6.2.2 Les benchmarks SquareRoot et Sum 


Le programme SquareRoot (voir fig. 11) permet de 
trouver la partie entiere de la racine carree du nombre 
entier 50. Une erreur est injectee a la ligne 13, qui 
entraine de retourner la valeur 8 ; or le programme doit 
retourner 7. Ce programme a ete utilise dans le papier 
decrivant I’approche BugAssist, il contient un calcul 
numerique lineaire dans sa boucle et non lineaire dans 
sa postcondition. 


class SquareRoot{ 

/*@ ensures ((res*res <= v a 1 ) (res+l)*{res + l)>val) ;*/ 

int SquareRoot() 

{ 

int val = 50; 
int i = 1 ; 

int V = 0 ; 
int res = 0 ; 
while (v < val ) { 

V = V + 2 * i + 1 ; 

i= i + 1; 

} 

res = i; /terror; the instruction should be res = 
i - 1 ./ 
return res ; 

} 

} 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 


Figure 11 - Le programme SquareRoot 































Avec un depliage egal a 50, BugAssist calcule pour 
ce programme les instructions suspectes suivantes : 
{9,10,11,13}. Le temps de la localisation est 36,16s 
et le temps de pretraitement est 0,12s. 

LocFaults presente une instruction suspecte 
en indiquant a la fois son emplacement dans le 
programme (la ligne d’instruction), ainsi que la 
ligne de la condition et I’iteration de chaque boucle 
menant a cette instruction. Par exemple, 9 : 2.11 
correspond a I’instruction qui se trouve a la ligne 
11 dans le programme, cette derniere est dans une 
boucle dont la ligne de la condition d’arret est 9 et 
le numero d’iteration est 2. Les ensembles suspec¬ 
tes par LocFaults sont fournis dans le tableau suivant. 


DCMs 

MCSs 

0 

{5},{6},{9; 1.11}, {9: 2.11},{9: 3.11}, 

{9 : 4.11},{9 : 5.11},{9 : 6.11},{9 : 7.11}, {13} 

{9:7} 

{5},{6},{7},{9 : 1.10},{9 ; 2.10},{9 : 3.10}, 

{9 : 4.10},{9 : 5.10}, {9 : 6.10},{9 : 1.11}, 

{9 : 2.11},{9 : 3.11},{9 : 4.11},{9 : 5.11}, {9 : 6.11} 


Le temps de pretraitement est 0,769s. Le temps 
ecoule lors de I’exploration du CFG et le calcul des 
MCS est 1, 299s. Nous avons etudie le temps de Loc¬ 
Faults et BugAssist des valeurs de val allant de 10 a 
100 (le nombre de depliage b employe est egal a val), 
pour etudier le comportement combinatoire de chaque 
outil pour ce programme. 


Programs 

b 

LocFaults 

BugAssist 

P 

L 

P 

L 

= 0 

^1 

< 2 

< 3 

VO 

10 

1.096 

1.737 

2.098 

2.113 

2.066 

0.05 

3.51 

VIO 

20 

0.724 

0.974 

1.131 

1.117 

1.099 

0.05 

6.54 

V20 

30 

0.771 

1.048 

1.16 

1.171 

1.223 

0.08 

12.32 

V30 

40 

0.765 

1.048 

1.248 

1.266 

1.28 

0.09 

23.35 

V40 

50 

0.769 

1.089 

1.271 

1.291 

1.299 

0.12 

36.16 

V50 

60 

0.741 

1.041 

1.251 

1.265 

1.281 

0.14 

38.22 

V70 

80 

0.769 

1.114 

1.407 

1.424 

1.386 

0.19 

57.09 

V80 

90 

0.744 

1.085 

1.454 

1.393 

1.505 

0.22 

64.94 

V90 

100 

0.791 

1.168 

1.605 

1.616 

1.613 

0.24 

80.81 



Figure 12 - Comparaison de revolution des temps 
de LocFaults avec au plus 3 conditions deviees et de 
BugAssist pour le benchmark SquareRoot, en faisant 
augmenter le nombre d’iterations en depliant la boucle. 


Programs 

b 

LocFaults 

BugAssist 

P 

E 

P 

L 

= 0 

< 1 

< 2 

< 3 

VO 

6 

0.765 

0.427 

0.766 

0.547 

0.608 

0.04 

2.19 

VIO 

16 

0.9 

0.785 

1.731 

1.845 

1.615 

0.08 

17.88 

V20 

26 

1.11 

1.449 

7.27 

7.264 

6.34 

0.12 

53.85 

V30 

36 

1.255 

0.389 

8.727 

4.89 

4.103 

0.13 

108.31 

V40 

46 

1.052 

0.129 

5.258 

5.746 

13.558 

0.23 

206.77 

V50 

56 

1.06 

0.163 

7.328 

6.891 

6.781 

0.22 

341.41 

V60 

66 

1.588 

0.235 

13.998 

13.343 

14.698 

0.36 

593.82 

V70 

76 

0.82 

0.141 

10.066 

9.453 

10.531 

0.24 

455.76 

V80 

86 

0.789 

0.141 

13.03 

12.643 

12.843 

0.24 

548.83 

V90 

96 

0.803 

0.157 

34.994 

28.939 

18.141 

0.31 

785.64 


Table 6 - Le temps de calcul pour le benchmark Squa¬ 
reRoot 

Le programme Sum prend un entier positif n de 
I’utilisateur, et il permet de calculer la valeur de 
*■ postcondition specific cette somme. L’er- 
reur dans Sum est dans la condition de sa boucle. File 
cause de calculer la somme i au lieu de X^Xi *■ 

Ce programme contient des instructions numeriques li- 
neaires dans le coeur de la boucle, et une postcondition 
non lineaire. 

Les resultats en temps pour les benchmarks Squa¬ 
reRoot et Sum sont presentes dans les tables respecti- 
vement 6 et 7. Nous avons dessine aussi le graphe qui 
correspond au resultat de chaque benchmark, voir res- 
pectivement le graphe de la figure 12 et 13. Le temps 
d’execution de BugAssist croit rapidement; les temps 


Table 7 - Le temps de calcul pour le benchmark Sum 

de LocFaults sont presque constants. Les temps de 
LocFaults avec au plus 0, 1 et 2 conditions deviees 
sont proches de ceux de LocFaults avec au plus 3 
conditions deviees. 

7 Conclusion 

La methode LocFaults detecte les sous-ensembles 
suspects en analysant les chemins du CFG pour trou- 
ver les DCMs et les MCSs a partir de chaque DCM; 
elle utilise des solveurs de contraintes. La methode Bu- 
gAssit calcule la fusion des MCSs du programme en 
transformant le programme complet en une formule 
booleenne; elle utilise des solveurs Max-SAT. Les deux 
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Figure 13 - Comparaison de revolution des temps 
de LocFaults avec au plus 3 conditions devices et de 
BugAssist pour le benchmark Sum, en faisant aug- 
menter le nombre d’iterations en depliant la boucle. 


methodes travaillent en partant d’un contre-exemple. 
Dans ce papier, nous avons presente une exploration 
de la scalabilite de LocFaults, particulierement sur le 
traitement des boucles avec le bug Off-by-one. Les pre¬ 
miers resultats montrent que LocFaults est plus efH- 
cace que BugAssist sur des programmes avec boucles. 
Les temps de BugAssist croissent rapidement en fonc- 
tion du nombre de depliages. 

Dans le cadre de nos travaux futurs, nous envisa- 
geons de confirmer nos resultats sur des programmes 
avec boucles plus complexes. Nous developpons une 
version interactive de notre outil qui fournit les sous- 
ensembles suspects I’un apres I’autre : nous voulons 
tirer profit des connaissances de I’utilisateur pour se- 
lectionner les conditions qui doivent etre devices. Nous 
reflechissons egalement sur comment etendre notre me- 
thode pour supporter les instructions numeriques avec 
calcul sur les flottants. 
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